Many systems employing microprocessors utilize a trusted machine state. A trusted machine state includes data retained by the system in order to more smoothly resume operation after reinitialization. This data can be used to aid the system in recovering from certain errors and to provide a non-disruptive code load (NDCL).
Systems using processors may be subject to failures which halt normal operation. For some of these failures, the system can recover from the failure and resume operation by initializing at least a part of memory. For example, conventional embedded control subsystems are used in a variety of devices, from simple video cassette recorders to data storage subsystems used in complex computer systems. These control subsystems typically control the device and allow the device to communicate with a user or host computer. Certain errors in conventional control subsystems halt normal processing. In order to continue execution, the conventional control subsystem reinitializes memory, then resumes operation. This allows the conventional control subsystem to continue operation despite the occurrence of the error.
During reinitialization, most local and shared memory is reinitialized. This allows data which may have caused the error to be removed from memory. However, the trusted machine state is typically retained. The data preserved in the trusted machine state allow the system to more smoothly resume operation. Typically, this data includes information relating to the certain variables used in the control subsystem.
In addition to use in recovery from certain errors, trusted machine states are also used in performing a conventional NDCL. The conventional NDCL allows a device currently running a particular set of code to switch from one version of the code to another without having to restart the system. In conventional NDCLs using a trusted machine state, the portion of memory retaining the trusted machine state is not reinitialized in the processes of halting the old program, loading the new program, and initializing the system. As a result, the new program is loaded without disrupting system operations. The data retained in the trusted machine state enables the device to resume operations which were in progress when the switch from one version of code to another took place.
A conventional method for providing a trusted machine state is simply to avoid reinitializing the portions of memory in which data for the trusted machine state is stored. In order to accomplish this, a software developer would typically omit code for reinitializing portions of memory in which the trusted machine state resides. As a result, only those portions of memory which do not hold a trusted machine state are typically reinitialized.
Although reinitialization of certain portions of memory should allow conventional systems to recover from certain errors and provide NDCLs, conventional methods for providing a trusted machine state are problematic. When a developer merely forgets to provide for reinitialization of memory an unintended trusted machine state arises. As a result, data is unintentionally retained through the reinitialization process. If this data was incorrect at the time an error halted operation or if the data is simply inconsistent with the state of other variables which were reinitialized, another error could occur after the system resumes operation. As systems become more complex, there is a greater probability of unintended trusted machine states. There is also a corresponding increase in the probability that an unintended trusted machine state will cause errors in execution once operation has resumed.
In addition, intended and unintended trusted machine states affect NDCLs. Because conventional methods for preserving the trusted machine states function by retaining data at specific addresses in memory, alterations between version of code must be limited in order to allow the switch from one version of code to another to be performed in a non-disruptive fashion which preserves the trusted machine state. Either the old and new versions of code must utilize the same addresses for the trusted machine state or the new code must read the addresses corresponding to the trusted machine state in the old code and write the trusted machine state to the addresses used by the new code. In either case, the developer of the new code should be confident that all of the old code's intended trusted machine states have been properly identified. Because trusted machine states are defined by the absence of reinitialization code, identifying intended or unintended trusted machine states is difficult and error prone. Thus, it is difficult to ensure that all trusted machine states are identified, particularly for a system having a great deal of code or numerous developers. Moreover, unintended trusted machine states could cause failures after the NDCL has been performed.
Accordingly, what is needed is a system and method for providing a trusted machine state with reduced probability for errors. The present invention addresses such a need.